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Motivation 



• Software exploitation is not generic anymore 

• There are different exploitation primitives in 
different contexts 

• A modern exploitation technique shows how 
to take advantage of those primitives 

• There are much more been 'computed' then 
only the code that was written (the target) 



Insecurity State 



• "Treat all systems as compromised" 

- "There's no such thing as 'secure' any more." -- 
Deborah Plunkett, NSA Information Assurance 
Directorate 

• "Long weeks to short months before a 
security meltdown" - Brian Snow, in 
December 2010 



Does prevention works? 



• Many initiatives in 'trustworthy computing' 

• Many books on 'secure programming' 

• Many academic publications 

• Lots of test methods: fuzzing, binary analysis, 
you name it 

- And STILL the software SUCKS and is EXPLOITED! 

• And about the hardware? We have no idea 
how bad it is... 



Insecurity is all about computation 



• Trustworthiness of a computer system is 
what the system can and cannot compute 

- Can the system decide if an input is 
invalid/unexpected/malicious & reject it? 

- Will program perform only expected computations, 
or malicious ones too? 

• Exploitation is setting up, instantiating, and 
programming a weird machine 

- A part of the target is overwhelmed by crafted input 
and enters an unexpected but manipulable state 



Decidability 



• Computation has some unsolvable 
(un-decidable) problems - 
about recognition of inputs! 

• An un-decidable problem does not have an 
algorithm that solves it for the general case 



Software Exploitation 



• A part of the target is overwhelmed by crafted 
input and enters an unexpected but manipulate 

state 

• Primitives are exposed 

- Memory corruption, implicit control flows 

- Unexpected control flows, ... 

• A "weird machine" is unleashed 

- A more powerful, programmable execution 
environment than intended or expected 



Software is Complex 



• Checks for input validity are 
scattered throughout the 
program, mixed with 
processing logic 

• Lots of additional computing 
options existent and available 
to the 'weird machine progran 
aka, exploit writer 




Weird Machine is Born! 




Exploiting Additional Computations 



• Finally we are in our talk line... 

• There are many computations inside a program 
that can be used to subvert the code execution 
(and some of then has nothing to do with the 
original code itself) 

• ROP is not new, exploits are using it since 2000 
(maybe even before) 



*nix Exception Handling 



• Binaries compiled with GCC and that support exception 
handling have Dwarf bytecode: 

- Describe the stack frame layout 

- Interpreted to unwind the stack after an exception occurs 

• The process image includes the Dwarf interpreter (part of 
the GNU C++ runtime) 

• Bytecode can be written to force the interpreter to perform 
any computation (Turing-Complete), including, but not 
limited to, setup a library/system call modifying registers 
such as stack and base pointers -> See James and Sergey 
previous work on Dwarf Trojans 



James Oakley and Sergey Bratus 



• Proved that Dwarf can replace code creating a 
Trojan completely using Dwarf bytecode 

• Proved that Dwarf is a complete development 
environment: 

- Can read memory 

- Can compute with values from memory/registers 

- Can influence the flow of execution of a process 



ELF Header 



Program Headers 

■ init 



■text 

■fini 

■eh frame hdr 

■eh frame 

■gcc except table 

■dynamic 

■got 

■data 

■symtab 

■strtab 



Section Headers 

v J 



ELF 



The executable has this format either on disk 
or in memory. 



Dwarf 



• Developed as a debugging format to replace STABS 

• Standard: h tt p : //d wa rf st d . o rg 

• Provide information such as code line, variable types, 
backtraces, others 

• ELF Sections: .debug_info, .debug_line, .debug_frame are 
defined in the standard 

• .debug_frame defines how to unwind the stack (how to 
restore each entry in the previous call frame) 



Linux Exception Handling 



• GCC, the Linux Standards Base and the ABI x86_64 adopted 
a very similar format used in the .debug_frame to describe 
the stack unwind during an exception: .eh_frame 

• It is not exactly the same as dwarf 

• It adds pointer encoding and language-specific data 

• As usual, the documentation is sparse and very limited: 

- Partially discussed in the Linux Standards Base 

- Partitially defined in the ABI 

- Partially implemented in GCC 



.eh_frame 

• Theoretically it is a table, where for each address 
in the .text it is describe how to restore the 
registers to the previous call frame 



EIP 


CFA 


EBP 


ESI W3SM 


RET 


OxfOOOfOOO 


rsp+16 


*(cfa-16) 






*(cfa-8) 


OxfOOOfOOl 


rsp+16 


*(cfa-16) 






*(cfa-8) 


0xf000f002 


rbp+16 


*(cfa-16) 




eax=edi 


*(cfa-8) 














OxfOOOfOOa 


rbp+16 


*(cfa-16) 


*(cfa-24) 


eax=edi 


*(cfa-8) 



• CFA (Canonical Frame Address) - Address relative 
to the call frame 

• Each line defines how each part of the code can 
return to the previous frame 



Size Limitations 



• Obviously, keep such a table would use more 
space then the code itself 

• That's why the adoption of bytecode: The 
table is 'compressed', providing everything 
required to create it when needed 

• Portions of the table are created as needed 
(on-demand) 



.eh frame 



.eh_frame section 

| CFI = Call Frame Information 
| | CIE = Common Information Entry 



DE | | FDE = Frame Description Entry 
.---.I | 

| *LSDA 1 1 | LSDA = Language Specific Data Area 
......... | | 



"The .eh_frame section shall contain 1 or more Call Frame Information (CFI) records. The number 
of records present shall be determined by size of the section as contained in the section header. 
Each CFI record contains a Common Information Entry (CIE) record followed by 1 or more Frame 
Description Entry (FDE) records. Both CIEs and FDEs shall be aligned to an addressing unit sized 
boundary" 




FDExCIE 



FDE (Frame Description Entry) exists for each logii 
Instruction block 

CIE (Common Information Entry) holds common 
Information between FDEs 



INSTRUCTIONS in FDE hold the DWARF bytecode 




FDExCIE 



initial_location/address_range: 

Defines for which instructions this FDE applies 

augmentation: 

Language-specific information 
return_address_register: 

Entry in a virtual table that defines the .text location 
to return to (eip) 

instructions: 

Table rules. Dwarf has a language to describe 
the table. 



Dwarf Instructions 



• Work as an assembly language (unexpected computations) 

• Turing-Complete Stack-Based Machine 

• Can access memory and register values 

• Have some limitations: 

- Cannot write to register/memory (but we can force out-of-order code 
execution and obtain writes) 

- Cannot call native code 

- Cannot write to registers that are not callee-saved in the ABI (we can 
write to callee-saved register thought) 

- GCC limits the stack in 64 words 



Dwarf Programming 



• DW_CFA_set_loc N 

Next instructions apply to the first N bytes of the 
function 

• DW_CFA_def_cfa R OFF 

CFA is calculed starting from register R and offset 
OFF 

• DW_CFA_offset R OFF 

Register R is restaured from the value in CFA OFF 

• DW_CFA_register Rl R2 

Register Rl is restaured with the contents of R2 



And the table is back... 

• Each architecture register receives a DWARF 
equivalent (the mapping is architecture specific) 

• Dwarf Instructions define rules for a column or 
advances to the next line (program location) 

• In a FDE, lines heritage from instruction lines 
above them 



EIP 


CFA 


EBP 


EBX 


EAX 


RET 


OxfOOOfOOO 


rsp+16 


*(cfa-16) 






*(cfa-8) 


OxfOOOfOOl 


rsp+16 


*(cfa-16) 






*(cfa-8) 


0xf000f002 


rbp+16 


*(cfa-16) 




eax=edi 


*(cfa-8) 



OxfOOOfOOa rbp+16 *(cfa-16) *(cfa-24) eax=edi *(cfa-8) 



Dwarf Expressions 



• To not anticipate all unwinding mechanisms of a system, the standard 
defines flexibility: 

- DW_CFA_expression R EXPRESSION 

R receives the value from the EXPRESSION result 

- DW_CFA_val_expression R EXPRESSION 

R restored to result of EXPRESSION 

• Expressions have their own instructions: 

- Constant Values: DW_OP_constu, DW_OP_const8s, etc 

- Arithmetic: DW OP plus, DW OP mul, DW_OP_and, DW_OP_xor, etc 

- Memory read: DW_OP_deref 

- Register read: DW_OP_bregx 

- Flow Control: DW_OP_le, DW_OP_skip, DW_OP_bra, etc 



Katana 



Emit a dwarfscript 

> $e=load "demo" 
Loaded ELF "demo" 

> dwarfscript emit ,, .eh_frame" $e "demo.dws" 
Wrote dwarfscript to demo.dws 

Dwarfscript assembler 

> $ehframe=dwarfscript compile "demo.dws" 

> replace section $e ".eh_frame" $ehframe[0] 
Replaced section ".eh_frame" 

> save $e "demo_rebuilt" 

Saved ELF object to "demo_rebuilt" 

> !chmod +x demo_rebuilt 



So what? 



• With Katana you can see and modify unwind 
tables in an easy way 

- Control the unwinding flow (how the call stack is 
handled) 

- Avoid an exception handler to execute another 
one 

- Redirect exceptions 

- Find/solve symbols 

- Calculate relocations 



Example 



• If function foo is responsible for an exception 

- Change flow to function bar 

- Thru static analysis, we see that bar is at 0x600DF00D 

- In the FDE, we change: 

DW_CFA_offset rl6 1 
-To: 

DW_CFA_val_expression rl6 
begin EXPRESSION 
DW_OP_constu 0x600DF00D 
dnd EXPRESSION 



.gcc_except_table 

• So far, redirected only to 'catch' blocks 

• The .gcc_except_table hold language-specific 
data (where the exception handlers are) 

- Interpreted by the personality routines 

- We can stop an exception at any time 

- Unlike the .eh_frame, do not have standards 

- There is no documentation, so let's see the code ;) 



Assembly 



• While compiling a program using GCC, do: 
-save-temps -fverbose-asm -dA 

.section .gcc_except_table,"a",@progbits 
.align 4 
.LLSDA963: 

.byte Oxff # @LPStart format (omit) 
.byte 0x3 # @TType format (udata4) 

.uleb128.LLSDATT963-.LLSDATTD963 # @TType base offset 
.LLSDATTD963: 

.byte 0x1 # call-site format (uleb128) 

.uleb128 .LLSDACSE963-.LLSDACSB963 # Call-site table length 
.LLSDACSB963: 

.uleb128 .LEHB0-.LFB963 # region start .uleb128 .LEHEO-.LEHBO # 
length .uleb128 .L6-.LFB963 # landing pad .uleb128 0x1 # action 

.uleb128 .LEHB1-.LFB963 # region 1 start .uleb128 .LEHE1-.LEHB1 # 
length .uleb128 0x0 # landing pad 

.uleb128 0x0 # action 

.uleb128 .LEHB2-.LFB963 # region 2 start .uleb128 .LEHE2-.LEHB2 # 
length .uleb128 .L7-.LFB963 # landing pad .uleb128 0x0 # action 
.LLSDACSE963: 

.byte 0x1 # Action record table .byte 0x0 

.align 4 

.long ZTIi 



Layout 



gcc_except_table 

language-specific 
data areas (LSDAs) 




J call site position 
call site length 
landing pad position 



1 



.offset to next action I 



Exception Handling Flow 



cxa_allocate_exception | 

< in libstdc-H- J 



_Unwind_RaiseException 
in libgcc 

unwind one frame 

call personality routine 

if no handler, loop 

return into handler 



_gxx_personality_vO 
in libstdc-H- 



read language specific data . 



User Code 
catch block 

bookkeeping 



bookkeeping 
execution continues 



__cxa_begin_catch | 
in libstdc-H- J 



__cxa_end_catch j 
in libstdc-H- J 



Exceptions are not asynchronous 



• Functions that call throwQ just call: 

- cxa_allocate_exception() -> To allocate space 

using malloc (or buffers in the .bss if malloc fails - 
gcc-xxx/l i bstd++v3/l i bsu pc++/e h_a I loc. :84) 

- And then cxa_throw() -> That will go thru the 

frames until a handler for the exception is found 



Proving (assembly) 



Dump of assembler code for function main: 
<+9>: mov $0x4,%edi # std::size_t thrown_size 

# Allocates a new " cxa_refcounted_exception M followed by 4 

bytes; we 

# do a M throw(l) M , 1 being an "int" occupies 4 bytes. 
<+14>: callq 0x400930 < cxa_allocate_exception@plt> 

<+25>: mov $0x0,%edx # void (*dest) (void *) 

<+30>: mov $0x6013c0,%esi # std::type_info *tinfo 

<+35>: mov %rax,%rdi #void*obj 

<+38>: callq 0x400940 <__cxa_throw@plt> 



cxa_allocate_exception() 

• Returns a pointer to a 

- struct cxa_refcounted_exception, which helds a 

reference to an object cxa_exception 

• cxa_throw() is then executed to: 

- Initialize the current context (register values) 

- Iterate in the stack until it finds the exception 
handler 



What We've Shown Before 



• Ret-into-libc 

• Used the dynamic-linker already in Dwarf to find 
execvpe 

• Used Dwarf to prepare the stack 

• In less than 200 bytes and less than 20 words in 
the stack (showing that a 64-stack word 
limitation is not an obstacle) 

• Started in an offset of execvpe where they can 
control the Dwarf registers (and not in the 
function beginning) 



What else can be done? 



• Old GCC had both, the .eh_frame and 
the .gcc_except_table as +W 

• Well... 

- Li bgcc/l i bstd C++ need to find those areas in memory, 
right? 

- The program header, GNU_EH_FRAME contains 
the .eh_frame location (dl_iterate_phdr is the 
function that finds it) 

- Libgcc caches the value! 



Fake EH 



• If we can overwrite the cached value, we are 
able to control the exceptions and leverage 
everything already explained 

• Libgcc does not export symbols, so we need to 
find an heuristic/reverse to find what to 
overwrite 



Caching 



• The pointer caching is done in: unwind-dw2-fde-glibc.c: 
#define FRAME_HDR_CACHE_SIZE 8 

static struct frame_hdr_cache_element 
{ 

_Unwind_Ptr pcjow; 
_Unwind_Ptr pc_high; 
_Unwind_Ptr load_base; 
const ElfW(Phdr) *p_eh_frame_hdr; 
const ElfW(Phdr) *p_dynamic; 
struct frame_hdr_cache_element *link; 
} frame_hdr_cache[FRAME_HDR_CACHE_SIZE]; 



Caching 



8 cache entries for the frame header 

- Uses a Least Used Replacement Algorithm (_Unwind_lteratePhdr_Callback()) 

- Most recently used is the head of the list 

In the test environment, the frame_hdr_cache was at 0x6e0 bytes from the offset of the writable 
data segment of libgcc 

• This is the aforementioned array, with 48 bytes in size 

The executable itself is the 3 rd element of the array (the first two are the libgcc and libstdc++) 

The offset for the writable data segment of libgcc can be found in this way (based in what we 
know): 

- 0x6e0+48*2=0x740 

The entry p_eh_frame_hdr that we want to overwrite is at 24 bytes of this structure. 



Example 



• Together with the paper/presentation, we 
release a demo program for the exploitation. 
Those are the test characteristics we see: 

- 0x7ffff760e000 -> libgcc loading address 

- 0x220000 -> offset for the writable data segment 
(starting from the lib base address) 

- 0x6e0 -> offset for the cache elements (starting from 
the writable data segment) 

- 48 bytes is the size of the structure 

- 2 entries before ours (readelf-d) 

- 24 bytes inside the structure is what we want to 
overwrite 



Exploiting 



• To simplify the exploitation, it is interesting to 
align the structures in known offsets/ 
controlled offsets: 

- .eh_frame in the example aligned to start exactly 
at 0x50 bytes from the start of the .eh_frame_hdr 

- .gcc_except_table aligned to start exactly at 0x200 
bytes from the start of the .eh_frame 



Memleak 



We need the value of EBP, so we going to use a memleak. It can be achieved in different ways, 
depending on the target program (e.g.: overwriting parameters to printf-like functions, or if the 
vulnerability is a format string, which is our sample case) 

To calculate the EBP_PREVIOUS we use %llx (format string), so we use 4 bytes of space in the buffer 
and advance the stack pointer in 8 bytes (so the premise for exploiting the sample program is to 
manage to leak the EBP): 



#to get the value of ebp_previous 
instr=r n %llx%llx%llx%llx%llx%llx%^^ 
%llx%llx%x%x M 
proc.sendline(instr) 

proc.expectfunknown command: [0-9a-f]* ([0-9a-f]*).*") 
ebp_previous=int(proc. match. group(l),16) 
info("\nfound ebp_previous = Ox%x" % ebp_previous) 



Heuristics 



• We know the size of the previous frame 
(disassembling), so we are capable of calculate 
the EBP of our frame: 

- ebp=ebp_previous-PREV_FRAME_SIZE 

• With our frame address, we can calculate the 
address of libgcc, since we know the offsets: 

- libgcc_reveal_location=ebp- 
LIBGCC_REVEAL_EBP_OFFSET; 



More Heuristics 



• The value that reveals the .text location of the libgcc is at 
0xffffc798 (discovered in the previous slide), and it is 0x679 
above ESP and 0x750 above EBP 

• The libgcc base is calculated using the previously revealed 
address and masking the 3 low nibbles. We also use a fixed 
value to adjust the result (found thru disassembly): 

- Iibgcc_base=(libgcc_revealed & OxFFFFFOOO) - 
LI BGCC_REVEAL_ADJ UST 

• The separation between .text and .data segments in libgcc 
is 0x19000 (x86): 

- libgcc_data_base=libgcc_base+LIBGCC_DATA_OFFSET 



Finalizing 



• Finally, we find the frame_hdr_cache and the 
respective p_eh_frame_hdr from the 
libgcc_data_base, as previously described: 

- frame_hdr_cache=libgcc_data_base 
+CACHE_LIBGCC_OFFSET 

- p_eh_frame_hdr=frame_hdr_cache 
+CACHE_ENTRY_SIZE*PREVIOUS_CACHE_ENTRIES 
+OFFSET IN CACHE ENTRY 



In the demo case 



• With all the values, we redirect the execution: 

- Function doWork starts at 0x0804936a 

- Throw is at 0x08049634 

- Distance: 0x2ca (call site 14 in the dict_mod.dws for the demo) 

- We force the execution of the l_am_never_called that is at 
0x08049842 (offset of 0x4d8 from doWork) 

• The Dwarf payload is injected in the dictionary been readed by the 
target program (instead of using a shellcode). We find the pointers, 
overwrite the caching target address and the desired catch block is 
executed. 



Other possibilities 



• If you have a Write N you can overwrite 

the .eh_frame entirely (if it is +W, what is not 
normal in new systems) 

• You can overwrite the .eh_frame using a 
shellcode 

• You can use a stagered ret-into-lib to remap 
the .eh frame as +W and then overwrite it 



THE END! Really is !? 
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